Amazon ElastiCacheがサーバーレスになって運用がバチクソ楽になった #AWSreInvent

AWS re:Invent 2023

#Amazon ElastiCache

#Amazon ElastiCache Serverless

#AWS

#Redis

quiver

2023.12.04

AWSが提供するRedis・Memcachedなどのキャッシュ系マネージドサービスAmazon ElastiCacheのサーバーレス版が2023年のre:Inventで発表されました。

Redis・MemcachedやAWSの知識を求めずに、運用負荷を大幅に軽減できるようサーバーレスに進化していました。

公式ドキュメントで案内されている ElastiCache Redis Serverless の起動方法は極限までシンプルです

$ aws elasticache create-serverless-cache \
    --serverless-cache-name CacheName \
    --engine redis

redis INFO コマンドの実行結果もシンプルです

svlr-xx.serverless.apne1.cache.amazonaws.com:6379> INFO
# Server
redis_version:7.1
redis_mode:cluster
arch_bits:64
run_id:0

# Replication
role:master
connected_slaves:1
slave0:ip=svlr-xx.serverless.apne1.cache.amazonaws.com,port=6380,state=online,offset=0,lag=0

# Cluster
cluster_enabled:1

メモリやCPUの情報はどこへ行ったのでしょうか?

これらからも、運用の手離れの良さが伝わってくるとは思いますが、ElastiCache Serverlessを評価する上で重要になるであろう、以下の3つの観点でRedisを対象にサーバーレス具合を確認してみました。

スケーラビリティ
可用性
費用

Amazon ElastiCache for Redisの種類

ElastiCache Serverlessに立ち入る前に、ElastiCache for Redisが提供する構成をおさらいします。

以下の3パターンが存在します(MemoryDB for Redisは除外)。

非クラスター型
クラスター型
- self-designed : ユーザーがプロビジョン
- serverless : re:Invent 2023で発表

非クラスターは初代ElastiCacheです。

1ノードにすべてのデータが乗る前提で、ノードのインスタンスタイプとフェイルオーバー先となるレプリカ数を指定します。シャード数が1固定のクラスター型ともみなせます。

より大きなデータを扱えるように、シャーディングに対応したのがクラスター型です。

Serverless登場前の従来型では、ノードのインスタンスタイプとシャード数と各シャードに用意するレプリカ数を指定します。例えば、シャード数が4で、各シャードを1xプライマリ、1ｘレプリカの2ノード構成とすると、クラスター全体では 4 shard x 2 node/shard = 8ノードとなります。

Serverlessの登場に伴い、ドキュメントでは"self-designed"、コンソールでは "design your own cache" 等と表現されています。

Serverless型はクラスターモードで動作しますが、ノードのスペック上限を指定するだけであり、シャード数やレプリカ数は指定しません(隠蔽されてます)。その上で、勝手にスケールアップ(キャパシティの小刻みな変動)やスケールアウト(シャード数の変動)します。

構成の違いを確認した上で、先程の3点を評価します。

Serverlessは水平･垂直にオートスケールする

クラスターモードで動作するServerlessはAurora Limitless のように、垂直方向(スケールアップ/インスタンスタイプ)にも水平方向(スケールアウト/シャーディング)にもスケールします。スケールアップの範囲をメモリサイズ・CPU性能で指定するだけです。

メモリ・CPU・ネットワーク帯域の利用状況に応じて動的に縦横にスケールするため、ワークロードの変動が大きいシステムに対して、キャパシティ計画は不要です。

スケールアップには、Peter DeSantisのre:Inventキーノートでも紹介されたカスピアン･プラットフォームが活躍しています。

※ DAT342:Introducing Amazon ElastiCache Serverless から

スケールアウト(シャード数変動)時のリバランスも、ユーザーには透過に行われます。

Serverlessは可用性を担保

従来型のElastiCacheはプライマリノードの障害に備えてレプリカノードを用意したり、AZ障害に備えてマルチAZでデプロイさせる必要がありました。

Serverlessでは、こういった可用性はプラットフォーム側が担保するため、ユーザーが意識する必要はありません。

Serverlessの費用は試算が難しい

3つ目のポイントは費用です。

費用は次の2本立てです。

データ容量: $0.151 / GB-hour
CPU性能/ElastiCache Processing Units (ECPUs) : $0.0041 / million ECPUs

※ レートは東京リージョン

メモリとCPUという異なる性質の２変数があるため、精緻な試算は難しいです。リスクを取れるサービスに実践投入し、スケール動作や費用を評価し、費用感や製品特性を把握しながら、適用範囲を広げていきましょう。

Serverlessは動的なワークロードを手離れよく運用するものです。ほとんど使われていないシステムに適用すると、非Serverless型よりも利用費がかさんでしまいます。

試しに、最低価格を比較してみましょう。

Serverless型の場合、CPU性能を無視すると、1時間あたり $0.151 です(1ヶ月で約$108.7)。 1シャードあたり2ノード構成のself-designedクラスターを最小インスタンスタイプのt4g.microで組んだ場合、1時間あたり $0.025 x 2 = $0.05 です(1ヶ月で約$36)

普段使わない開発環境はコスト削減のため非Serverless型、ワークロードが大きく変動する本番環境はServerless型というように、構成を変える必要もでてくるでしょう。

最後に

ElastiCacheがServerlessになって大きく変わった3点、スケーラビリティ・可用性・費用について解説しました。

Redis/Memcachedのシンプルさ故か、ElastiCache ServerlessはすでにGA扱いであり、サーバーレス型でプロビジョンするだけでクライアント･プログラムを改修することなく、エンドポイントを変更するだけでElastiCache Serverlessを利用できます。

難しいことを考えずに手離れよくRedisを運用したい場合、ElastiCache Serverlessは十分に評価に値するでしょう。

今回紹介した点以外にも、RDS Proxy相当の機能が内蔵されていたり、ノイジーネイバー問題を対処してくれたり、マイナーバージョンやパッチがゼロダウンタイムで自動適用されたりと、ElastiCache Serverlessの運用機能は至れり尽くせりです。詳細はニューローンチセッション「DAT342:Introducing Amazon ElastiCache Serverless」をご確認ください。エンジニアなら、動的シャーディングをどうやって実現しているのか、気になりますよね?

なお、既存クラスターをサーバーレス型と非サーバーレス型間で切り替えできない点にはご注意ください。

それでは。